你在 IDE 的下拉選單裡裝了四個 Agent：一個寫程式、一個跑測試、一個整理文件，最後一個負責發版。介面看起來分工得很清楚，但切換選項後，它們讀到的還是同一個 workspace，也都能呼叫同一組 terminal 與 MCP actions。
這種配置只是換了執行者，沒有換權限。
如果寫 README 的 Agent 也能執行 migration，跑測試的 Agent 也握著 production token，那個下拉選單不是權限模型。團隊只是把一把萬用鑰匙輪流交給不同模型，再期待它們各自守規矩。
Qt 已公告，Qt AI Assistant 將在 2026 年 9 月 30 日停止交付，並於同年 12 月 31 日結束支援。官方把後續投資轉向 skills、MCP 與 agentic development，也明確區分了單輪助理和能分析專案、修改檔案、執行命令、觸發建置的多步驟工作流程。
這不表示所有 IDE 內建助理都會退場。比較值得注意的變化是：IDE 的責任正在改變。以前它提供一個 AI 輸入框，現在它可能要承載多個 Agent，讓它們取得編輯器狀態、專案內容與可執行動作。
Qt Creator 20 的 ACP Client 可以接入不同 Agent，MCP 服務則能暴露 Qt 與 IDE 能力。Google Cloud Developer Plugin 也把 skills、官方文件、MCP server、驗證流程與 gcloud 操作的 guardrails 包在同一個工具包裡。這些機制讓「接得上」變得比較有規則，但不會替團隊決定哪個 Agent 可以碰 production。
連接協定處理入口，授權仍是團隊自己的工作。
多 Agent IDE 至少跨過四個能力面，而且不該用同一個全域開關控制。
context read 決定 Agent 能讀哪些 repository、文件、IDE state 與建置輸出。唯讀也不是無害；測試 log、tool return 或暫存檔仍可能帶出不該進入模型 context 的內容。
workspace write 決定它能改哪些路徑、建立哪些 artifact。文件 Agent 可以更新 CHANGELOG.md，不代表它也該改 src/auth/**。
command execution 管的是可執行命令。pnpm test、資料庫 migration 與任意 shell 的風險完全不同，把它們都塞進「允許使用 terminal」只會讓審查失去意義。
external side effect 包含 deploy、publish、上傳檔案、修改雲端設定與對外發送訊息。這一層最好獨立核准，因為 Git diff 通常看不到外部系統已經發生什麼事。
Codex Python SDK 0.154.0 的 ExternalMessage 提供了一個很具體的提醒：外部內容可以啟動或加入同步、非同步 turn，帶有 tool-level authority，卻不會因此取得 user authorization。這是該版本 SDK 的介面語意，不是所有 Agent 協定的通用規格，但能力與使用者授權本來就該分開記錄。
我會先替任務分類，再為每次執行建立一個小型 capability envelope。下面不是 ACP、MCP、Qt 或 Codex 的官方 schema，而是一份團隊可以自行維護的 routing policy。
ryanvale
routing_policy:
- task_class: code-change
agent_role: coding-agent
read_scope: ["src/**", "tests/**", "package.json"]
write_scope: ["src/checkout/**", "tests/checkout/**"]
command_scope: ["pnpm test checkout", "pnpm lint"]
external_side_effect: denied
approval_owner: feature-owner
evidence: ["git diff", "changed-files.txt"]
- task_class: verification
agent_role: test-agent
read_scope: ["src/**", "tests/**", "artifacts/build/**"]
write_scope: ["artifacts/test-results/**"]
command_scope: ["pnpm test", "pnpm typecheck"]
external_side_effect: denied
approval_owner: ci-owner
evidence: ["test-report.xml", "command-log.txt"]
- task_class: release-docs
agent_role: docs-agent
read_scope: ["CHANGELOG.md", "docs/**", "artifacts/test-results/**"]
write_scope: ["CHANGELOG.md", "docs/releases/**"]
command_scope: []
external_side_effect: denied
approval_owner: release-owner
evidence: ["docs diff"]
- task_class: social-asset
agent_role: asset-drafter
read_scope: ["docs/releases/**", "brand/**"]
write_scope: ["artifacts/social-candidates/**"]
command_scope: ["render-preview"]
external_side_effect: denied
approval_owner: release-owner
evidence: ["artifact path", "preview checklist"]
- task_class: publish
agent_role: publisher
read_scope: ["approved release bundle"]
write_scope: []
command_scope: ["publish-approved-release"]
external_side_effect: approval-required
approval_owner: human-release-manager
evidence: ["approval record", "release URL"]
欄位不必一次做到很豪華，但有幾個不能省。read_scope 和 write_scope 要分開，否則「可以理解整個專案」很容易被誤解成「可以修改整個專案」。command_scope 應列出允許的命令，而不是只寫 terminal: true。external_side_effect 則要讓 deploy 與 publish 明確停在人工核准前。
evidence 也不能只填「Agent 已完成」。程式修改要留 diff，測試要留原始結果，資產要留檔案路徑，發佈則要有外部 URL。每一種任務的完成證據不同，不能全靠對話摘要代替。
假設今天要發布一個前端版本。Coding Agent 只改指定的 source path；Test Agent 讀取修改後的 workspace，但只執行 allowlist 裡的測試命令；Docs Agent 根據 diff 與測試結果更新 release note。三段工作可以共用 artifact，沒有必要共用完整權限。
到了社群圖片這一步，我反而不會為了「全自動」硬塞進 Agent。若需求只是把候選圖整理成不同平台尺寸，可以由人接手，在 Resize Image For 這類瀏覽器本機工具完成 resize、crop、padding、preview 與 export，來源圖片不必送到伺服器處理。這個低頻步驟很快，卻可能逼 Agent 多拿檔案、網路或帳號權限；留在 manual lane 往往比較容易審查。
最後的 publish 任務再建立一個新的 capability envelope。它只能讀取已核准的 release bundle，收到指定負責人的 approval 後才能執行，而且必須回傳可查驗的 release URL。前面任何一個 Agent 做完自己的工作，都不會自然繼承到這一步的權限。
「這是我們最信任的 Agent」不是有效的授權規則。同一個 Agent 讀文件時可以是低風險，改付款程式時需要較窄的 write scope，碰到 deploy 時又必須停下來等人。權限應該跟著 task instance 走，任務結束就失效，而不是綁在模型品牌或 IDE 裡的顯示名稱上。
多 Agent IDE 成熟與否，不用數它接了幾個模型。切換執行者時，團隊如果能立刻回答哪些讀取、寫入、命令與外部副作用跟著改變，哪些權限仍握在人手上，這套系統才真的具備分工。
iThome鐵人賽
看影片追技術